STORES Tech Conf 2024
https://gyazo.com/456e9dcac5585a1a2488d6a622ab7dd4
昨今何が起こっているか
AIが合理的と感じられる判断を行えるようになっている しかし、人間にしかできないこともあるのではないか？ 残された仕事について語る
概要
キリスト教にはない考えを持たせる
理性
人間の論理的思考や推論の脳直
知識の源泉
理性によって人や社会のあるべき姿は解明できると拡張したもの
動作メカニズム
言語パターンを学習して文脈に基づいて最適な応答を確立的に予測
論理的思考や推論ができる
つまり全部やらせればいいのではないか？
現在能力の限界はあるが、能力の向上が止まる確証はない
止まらない確証もないが
唯一の解があるなら任せられるのではないか
そもそも「何事も答えがあってそれには一つの体系がある」この前提は正しい？
この話をするのは社会的な営みとされている
アイスキュロス「アガメムノン」の話
戦争に負けるか、娘を生贄に捧げるかの話
道徳的ジレンマはあるが選択をしなければならない
ここに解はない
合理主義の一つの体系がすべてを説明する、仮定のほころびがある
どちらかを選べないから
キャリアの問題はここに近い
国内スタートアップ、外資テックジャイアントの選択
複数の両立しない価値がある
悲劇はここの典型例
両立しないけど対話ができる・共感できる・妥協できるという立場
完全な合理性は現実的に無理という前提
行動するのが前提のもの
これはLLMでも同じ
だいたい動く合理主義で我慢する路線
見解が一致する価値もあるのではないか？
両立しなくても提案できるのかもしれない
人間も限定的な合理性で満足してるじゃん
失業の可能性
残された仕事は？
我々の仕事とはなにか
新製品、新技術を毎日やっている
新しく何かをつくること
多元主義
しかし人は選択、行動、結果を引き受けて未来に進むことができる 限定合理性
しかし人は選択、行動、結果を引き受けて未来に進むことができる https://gyazo.com/f39658d5b9c3f2af2b61dfa7dc059872
繋がっていくサービスを支える開発環境作り
Shia
技術基盤グループ
https://gyazo.com/31e955709c88e03e9c437abb7f4d1e5f
イベントリポジトリ
開発環境の特徴
１つのチームが複数のサービスを触る機会が多い
インフラ環境・開発発言がバラバラ
サービス買収による影響
開発サーバはDocker Composeで動かす
課題
複数を動かすのは大変（バリエーションが多い）
localhostが使えない
ドメインに紐づける
社内向けループバックドメイン
単一エンドポイントを用意する
サブドイメインやパスをみてルーティングする
TLS証明書が必要
STORES-composeで動かす
必要なものだけ立ち上げるようにする
どのサービスにリクエストしてるかがわからない
失敗した場合はフォールバックするハンドラを実装
どこのサービスを実行するかが表示される
サービス登録が大変
構成要素が多い
設定を書き間違えるとデバックが大変
抽象化設定を用意して起動時に必要な情報を書き込む
サービスAにサービスBが必要な話
リモート環境から取得するものがあればそのまま使う
API Gatewayどうしよう
リモートにまとめる
ローカルで動かす場合認証認可はどうする？
ダミーauthorizerを用意する
Event Repositoryどうしよう
Webhook URLを登録する話
イベントブローカーを用意する
リポジトリを購読している
そこを購読できる立ち位置
ローカルに流す
サービス間ルーティング
https://gyazo.com/2ba74158d5f47d0437b919d4eb3da487
https://gyazo.com/3b352239857bb70530a514412d23317ehttps://gyazo.com/d64062934dc37d94094d0548f8793e42
課題はまだまだある
マシンパワー足りる？
開発はホストの方が良いのではないか？
リブートのたびにコンテナを毎回再起動したくない
サービスを一気に起動したいユースケースもある
chuka
モバイル開発本部 決済グループ
金額入力画面のここが楽しい
円形エフェクトが楽しい！
波紋の広がり方が楽しい！
ドラッグに追従して楽しい！
数字が飛んでいって楽しい！
問題点
入社当時はJava
現在はKotklin
Android Viewがわからなかった
最終更新実質5年前
複雑で難解！
キーを１つ作る
押下時のアニメーションを作る
押下の状態をつくる
円形エフェクト
ジェスチャーの判定
detectTapGestures
キーパッドらしく配置する
LazyVerticalGrid
ドラック時の実装をする
1. ドラッグジェスチャーの検出
2. ポインタ位置の検出
3. １と２を組み合わせる
https://gyazo.com/9f57b8835e8843c660e4247daf82aebd
Taiki Yokokawa
開発B本部 プロダクト基盤グループ
https://gyazo.com/b10ea98e4d6e33d3f7c0692e0f6592ca
https://gyazo.com/22b0b19d30dc2b4fb5446285192aadc5https://gyazo.com/f7794262cc144b6579ca501c588d0a17
直面した課題
再認可の挙動をどうするか
トークンを上書きする場合後から認可した事業者しか連携ができない
ユーザー目線だとつらい
同時に複数の認可は不可にする
連携する事業者の変更は明示的に連携を切って再認可
発行済みのアクセストークンも認可済対象を変更したい
店舗に対してアクセス権限がある
事業者に対して権限がもつようにしたい
ID基盤に流して店舗からIDに変更・更新するとよさそう
設計開始で３ヶ月後にリリース
デプロイ完了
発行済みのトークン認可対象の更新するだけ
リリースが失敗した
CPU使用率が急上昇した
DB負荷がスパイクした
処理内に重いクエリがあってテスト環境では気づけなかった問題
やり方を変更する
必要なデータをCSVで受け取ってID基盤でバッチ処理を実行する
2週間後に再リリースして成功、トークン自体も更新できた
末重拓己
テクノロジー部門・データ本部
創業初期からデータ機能面で連携した複数プロダクトを扱う会社
自社製品を広めやすい戦略
バンドル化によってデータ・機能面で付加価値を付与する
併用利用を超えた価値を提供したい
どういう価値があるのか
データ連携
会員情報
機能連携
ログインを1回で済ませたい
プライシング
自社においてもネガティブなものがないかも検討する必要あり
業種の組み合わせによって刺さるデータも違う
シミュレーションの数だけ全パターンを網羅した複雑なシートを用意しないといけない
基礎データを渡される
事業者ID別にシミュレーションをクエリで行いコード管理の仕組みを援用し管理するようにする
データマート上で構築する
クエリ管理が可能
管理・変更が俗人化しない
可視化が容易になる
BAツールと連携していることがあるのでビジネス・経営サイドで簡単に見えるようにする
https://gyazo.com/1c4c7d517cedb7bec1000a661a00210d
データマートの構築
総額の未来データをとってくる
各IDに分配する
一定の基準とは？
GMVや売上、前年度別などで比較
対象フラグ
従量課金割引
ソフトウェア費
シミュレーション期間
などなど
必要な指標を計算する
CROSS JOINでシミュレーション変数を用意
https://gyazo.com/9b096df02e5b9631fb7f504ef84e9267https://gyazo.com/157de1c9c10bf3cbcd4851cfee834fc2
https://gyazo.com/4db2beeedce2d0b95d55553b3004d61b
satoryo
モバイル開発本部 レジ・予約グループ
ネイティブアプリ
UIフレームワーク
カレンダー実装ライブラリ
bannzai
CalendarLib
構成要素
スタッフ
タイムライン
予約情報
1日の予約情報を表示、縦横にスクロールする
実装要件・仕様
https://gyazo.com/ed7cb0c149d9dfbde74d4931d3e91441
必要なパーツを検討する
ScrollView
GridView
これらではうまくいかなかった
スクロールする場合、縦横の要素をそれぞれ同時にスクロールさせたい
片方が動いたら片方連動したい
ScrollViewを同時に動かすものがある
https://gyazo.com/b844159cf916f15b4448fe84784ee8a2
課題点
予約数が増えるとその分重たくなる
UI操作
zukky
ricky
makky
なぜ本番環境が必要なのか
テスト環境
高額決済などの確認ができる
本番環境
本物のお金を使って確認ができる
ユーザーと同じ環境で確認したい
テスト計画
テスト分析
テスト設計
分析設計レビュー
テスト実装
テストケースレビュー
検証
終了作業
成果物からプロセスを改善していく
どのような検証か
決済機能の正常動作
クレジットカード
電子マネー
WeChat Pay
いつ行うか
推奨端末・OSの追加を行う
プロジェクトの最終的な動作環境
外部連携との連携との検証
レシートをメールで送信できるか
プリンターからのレシート印刷
Money Foward、Freeeとの連携
テストでは発生させられない
テスト環境では残高不足の概念がない
好きな金額で好きなだけ決済ができる
機能追加・改修の内容に合わせた研修
選定・精査の基準
決済・返金できるか
本番で担保する必要があるか精査
本番環境でできないものがある場合はテスト環境で徹底して検証する
クレジットカードのブランド網羅
契約が難しい
クレジットカードは売っているものではない
テスト計画の時点で本番環境のケース内容を考慮する
代替案を用意する猶予が生まれる
リスクが出る場合
品質リスクを洗い出す
共有する
PdMと開発とで合意を取る
できない時のリスクをしっかり考える
気をつけないといけないこと
会計処理の都合
環境ごとに使用する機材を使い分ける
返金できるものは当日中に返金処理を行う
本番環境で検証用クレジットカードを使ってしまう
検証カードのデータが本番環境に残存してしまう
指定アカウント以外の決済
開発A本部 サービスGTMグループ
11年目
コア開発者13人
難しさ
多機能さ
月謝・回数券ごとに有効期限や予約可能回数
移行過程の複雑さ
店舗アカウントが３世代前
ロジックの難しさ
予約可否の計算
47万行
1087Model
705Contoroller
コードを読まずに理解するにはどうしたか？
SRORES予約ブートキャンプ
アプリ操作に慣れるためのクイズ集
初級・中級・上級・超上級
触りながら慣れる
欲しいデータを作るやり方を学ぶ
ニッチな機能をカバーする
主要13モデルに絞る
最も重要なモデルとの関係がわかる
ドキュメントを呼ぶ
一番ドキュメントが集約してる
予約開発チームがもっとも使う
知らないことがあったらここを調べる
なかったら追加していく
教えてもらう
知ってる人に聞くのが手っ取り早い
1on1で教えてもらった場合はドキュメントを残す
LTしてもらう
知りたい概念を知ってそう人にLTしてもらう
どうやってコードを読むのか
解きたいことを明らかにする
何を解決したくてコードを読むのか
コードの中で迷子になりやすいので
関連情報がないかを探す
実装時PR
ざっと流れを追う
クラスやメソッド名に着目
実際に知らない機能を調べる方法
こたえ：権限が読み取りのみになっていた
問題を切り分ける
どこまで成功しているのかを探す
リクエスト・レスポンスログを出しているところを探す
どこから探すのかわからない
calendar_idで検索した
連携成功したやつしか残ってない
該当の予約の時の連携情報がどうなってるかを探す
「お急ぎ便対応予定が連携されない」というページがあった
いくつかできないパターンのページが存在していた
読んで触ると理解が進む
コードベースのくせに慣れる
原田陽紗子
開発B本部 新領域開発グループ
STORESはM&Aを繰り返して巨大になってきた
「今月の売り上げをまとめてみる」機能
データ分析β（moana）
売上やアクセスなどのデータを一元集計、GUIで操作
データ分析の中央集権などに扱いたい
コンポーネントベースのUI開発に混ぜて使えるようにしたい（ミニデータ分析β）
絶賛試行錯誤中
クロスフレームワークが大変
どう対応するか
React./ Vue
フレームワーク依存
工数２倍
フレームワーク依存しない
枯れている技術
クロスドメイン間の問題
1個で済む
Reactコンポーネントライブラリをつくる
NuxtのSSRは解消していない
使ってないので保留
バンドル結果がでかくなってる
react-domが原因？
サイズは減った
ブラウザで動かない
エイリアスの問題がありそう？
バンドルしないで依存関係にもたすのが良さそう
New Ruby Engineering
Koichi Sasada
Yusuke Endoh
よくある話
商売をさせてもらっている・大きい責任をもっている
Rubyは50兆円稼いでいる
嫌なところもよくみえる（20点分）
性能をよくしたい
人々の不満が将来の評価にどう関わるかはわからん
開発支援が弱い不満はある
2030年までにやること
型っぽい開発体験
@mametter: TypeScriptの型チェックはパスするんだけど、実行するとエラーになるコードを見つけた。怒ってくれるオプションとかあるのかな const f = () => x;
f(); //=> Cannot access 'x' before initialization
const x = 1;
雑な感じがする
型のように振る舞うようにしたい（まじめにやらない）
ユースケースごとに対応してる
問題があったらそこを叩く形で対応している
5年後にはこれを使う人が増える？
あ、軽い並行言語
軽い言語を目指したい
エコシステムが回り出したら考えるかも
より速い
よりwarmup timeが短い
よりメンテしやすい
やりたくないコードを書いてくれる
プログラミング言語は人間に読みやすい中間言語になるのではないか？
短ければ短いほどいいのではないか
資源を気にしなくていいこともあるのではないか
5年後はあまり変わってないのではないか